[00:05.920 --> 00:09.720]  Hi everyone and welcome to this introduction to ACARS.
[00:10.900 --> 00:15.400]  I'm an aeronautical engineer, pilot and hacker at Pentest Partners in the UK
[00:16.320 --> 00:21.680]  and I lead our aerospace work and research program. I've had the honor of working in all
[00:21.680 --> 00:27.240]  sorts of environments from government networks and consumer IoT through to planes, trains and
[00:27.240 --> 00:33.440]  automobiles. What we're going to be talking about is an avionics system called ACARS,
[00:33.440 --> 00:38.660]  which is really just a way of sending text messages between ground and airborne stations.
[00:39.280 --> 00:42.400]  This is a light touch on the topic but I'll cover the history of it,
[00:42.400 --> 00:48.100]  how it's transmitted, what it's used for and current airline ops, how to decode and decipher
[00:48.100 --> 00:54.880]  it and explore where the potential security issues with it are. Really what ACARS is now
[00:54.880 --> 00:59.060]  is a data link and this has become really important in keeping up the efficiency and
[00:59.060 --> 01:07.300]  safety of modern aircraft. So the start of the jet age of commercial passenger flying in the 1960s,
[01:07.300 --> 01:13.640]  communication was pretty basic. It was voice only between aircraft and the ground. Airlines did,
[01:13.640 --> 01:19.080]  and still do, pay their flight crews by block time, which is the moment from the doors closing
[01:19.080 --> 01:23.960]  and the aircraft taxiing now to the moment the doors open again at the arrival gate.
[01:24.140 --> 01:28.140]  I think it's probably derived from when the ground crew pull the chocks or blocks out
[01:28.140 --> 01:34.780]  from the wheels to allow the aircraft to move. In the 1960s and 70s, crews would radio their off-block
[01:34.780 --> 01:39.500]  times to a human on the ground, who would transcribe that into a teletype machine
[01:39.500 --> 01:45.940]  and send that onto the airline's base. Remember that airlines routinely fly into airports
[01:45.940 --> 01:50.880]  where there's no direct representation of that airline on the ground, so some form of remote
[01:50.880 --> 01:56.840]  communication is needed back to HQ. Looking for efficiency, I guess a euphemism for not paying
[01:56.840 --> 02:01.400]  crews any more than they need to. ACARS was developed as a kind of automatic time clock
[02:01.400 --> 02:09.040]  system, sending the details of the out, off, on, and in times by radio. Because radio is line of
[02:09.040 --> 02:14.220]  sight only, ARINC, those who developed the standard, built out a network of ground-based
[02:14.220 --> 02:19.380]  transmitters to send, receive, and reload those messages around. And this whole concept hasn't
[02:19.380 --> 02:27.420]  really changed much to this day. So here we are today then. Plain old ACARS is broadly what it
[02:27.420 --> 02:33.500]  was back in 1978. It uses a VHF radio and a network of ground transmitters to send these messages
[02:33.500 --> 02:41.480]  around. A later evolution is ACARS over Aviation VHF Link Control, which is a terrible mashup of
[02:41.480 --> 02:48.220]  acronyms. IT being aerospace. This still uses a VHF line of sight radios, but on a different
[02:48.220 --> 02:54.820]  frequency to give a slightly higher bandwidth. For areas outside of direct ground contact,
[02:54.820 --> 03:01.530]  like over the Atlantic, High Frequency Data Link, HFTL, can also be used, but it's very slow.
[03:02.300 --> 03:06.760]  Nowadays we have SATCOM, which is increasingly the transmission mode of choice for many airlines
[03:06.760 --> 03:12.840]  and aircraft. There is some experimentation with using the cellular GSM networks as an ACARS
[03:12.840 --> 03:19.400]  platform too, but it's only in use for one European carrier, to my knowledge. There are
[03:19.400 --> 03:25.460]  several classes of load, I suppose you would call them, in the ACARS network. The aircraft themselves
[03:25.460 --> 03:30.580]  and ground stations like the airlines and air traffic control, as we'll see later.
[03:30.860 --> 03:37.120]  In order to route a message from an aircraft flying over, let's say Spain, back to the airline
[03:37.120 --> 03:43.820]  HQ in the UK, a Data Link Service Provider is paid to pick up, route, and deliver these messages.
[03:44.320 --> 03:51.560]  You have two Data Link Service Providers, DSPs, to choose from, CITA and Rockwell. Rockwell bought
[03:51.560 --> 03:58.240]  ARINC Inc., including the ACARS network, back in 2013, so you might see ARINC slash Rockwell
[03:58.240 --> 03:59.880]  used interchangeably.
[04:01.780 --> 04:09.240]  So as we've said, the original plain old ACARS, and ACARS over ABLC, used VHF radios, so a new
[04:09.240 --> 04:14.580]  direct line of sight. And that includes the earth being round, of course, to a ground station.
[04:14.940 --> 04:20.360]  Aircraft are often flying pretty high up, 35,000 feet or more, so actually the range of a single
[04:20.360 --> 04:25.860]  transmitter is still quite large. But you can see from CITA's coverage map here, there are lots of
[04:25.860 --> 04:33.040]  gaps over oceans, Africa, and places aircraft tend not to fly very much, like northern Canada.
[04:33.660 --> 04:37.280]  Running all of these transmitters and maintaining the communications links between them
[04:37.280 --> 04:42.780]  is pretty expensive. Satellite coverage is also dependent on where you are in the world,
[04:42.780 --> 04:48.540]  although to a lesser degree. InMarsat have coverage between plus and minus 80 degrees latitude,
[04:48.540 --> 04:55.860]  although Iridium have more lower satellites and can offer polar coverage too.
[04:56.040 --> 05:02.240]  There are only 15 high frequency transmitters in the world. They have long reach and are located
[05:02.240 --> 05:09.260]  for polar and oceanic coverage. The costs are a bit opaque, but one Asian carrier was paying
[05:09.260 --> 05:16.620]  the equivalent of a thousand dollars per megabyte on their HF service. AOA and POA are still not home
[05:16.620 --> 05:22.220]  broadband prices though, and there is a bit of an old adage in that for aviation you add another
[05:22.220 --> 05:29.220]  zero onto the end of what seems a reasonable price for anything. Original ACARS uses a signal
[05:29.220 --> 05:34.780]  with each bit encoded as a half bit sine wave on top of the carrier, which you can see in this nice
[05:34.780 --> 05:40.840]  waterfall image that most software-defined radio signals will generate for you. The modem will
[05:40.840 --> 05:46.160]  briefly listen to avoid transmitting at the same time as others and send a starting tone
[05:46.620 --> 05:53.070]  and then the serial data. And you can hear this as a fairly distinctive old-school style modem noise.
[05:54.800 --> 05:59.990]  As is VHF, a line-of-sight, each geographic region uses a different frequency.
[06:00.360 --> 06:07.280]  And this is per data link service provider as well. So ARINC, Rockwell, in Europe is a different
[06:07.280 --> 06:13.080]  frequency to CITER in Europe. And the aircraft's modem will usually automatically switch frequencies
[06:13.080 --> 06:22.540]  between them based on its known position. VHF Data Link 2, so AI, is an enhancement that uses
[06:23.080 --> 06:28.860]  phase shift keying modulation to give a slightly higher bandwidth throughput. It also uses the
[06:28.860 --> 06:34.600]  X25 routing protocol to send messages between data terminals. And I guess this sort of matches
[06:34.600 --> 06:41.980]  up with the lowest three layers of the OSI model, but this X25 predates TCPIP by some considerable
[06:41.980 --> 06:50.180]  time. Because of the use of X25, there is a global single frequency, but as with planar ACARS, it's
[06:50.180 --> 06:59.100]  VHF and so still line-of-sight. So several satellite communication service providers offer
[06:59.620 --> 07:06.660]  ACARS, including Inmarsat and Iridium, both have global coverage. But as Inmarsat has
[07:06.660 --> 07:11.180]  geostationary satellites, there is no reception between plus and minus 80 degrees latitude,
[07:11.180 --> 07:16.740]  as we can see in their coverage map. Iridium has a larger constellation of lower flying birds
[07:16.740 --> 07:22.580]  to give complete coverage even over polar regions. There are different bandwidth and frequency
[07:22.580 --> 07:27.960]  options and services from each provider, but certain frequencies are better at penetrating
[07:27.960 --> 07:34.780]  water. Although aircraft tend to fly above clouds and weather, and this is not usually a problem,
[07:34.780 --> 07:42.000]  but in the tropics, humid air can block signals. It is possible to intercept ground-to-air,
[07:42.000 --> 07:47.180]  that is ground-to-satellite-to-aircraft communications using a suitable antenna and
[07:47.180 --> 07:53.360]  software, as a signal is transmitted to the ground over a wide area. But you will not be able to see
[07:53.360 --> 08:00.480]  aircraft to ground, as you're not in a middle position unless you're in space. The data is
[08:00.480 --> 08:05.820]  relayed from the ground stations back into the DSP networks and then on to its destination.
[08:06.640 --> 08:12.280]  Classic aero services are quite bandwidth-limited, but we've probably all been on aircraft with
[08:12.280 --> 08:19.440]  in-flight Wi-Fi by now, so SATCOM program actually can be quite decent, and it's this latter capability
[08:19.440 --> 08:25.400]  that is now being used in modern E&A aircraft to collect huge amounts of live data for analysis
[08:25.400 --> 08:32.680]  and predictive maintenance. There are also options to transmit ACARS over long-wave,
[08:32.680 --> 08:37.540]  high-frequency transmitters, and this is reserved for oceanic and polar regions.
[08:37.540 --> 08:42.520]  There are actually only 15 transmitter sites and speeds are incredibly slow,
[08:42.520 --> 08:46.440]  and this probably also explains the very high costs of using these services.
[08:48.580 --> 08:53.740]  There is an early test of using the CELIN networks to provide ACARS services in Europe.
[08:53.740 --> 08:58.720]  This actually uses a piece of equipment found on many aircraft already, which is a wireless
[08:58.720 --> 09:05.340]  quick access recorder or wireless digital flight data acquisition unit. These devices capture lots
[09:05.340 --> 09:10.000]  of data in flight and then relay it back to the airline once they're on the ground over a 3G
[09:10.000 --> 09:17.080]  network. This same unit can be upgraded to provide a wireless link and route ACARS over that instead.
[09:19.490 --> 09:24.090]  Aircraft will often maintain multiple communication links, and for a transatlantic
[09:24.090 --> 09:30.650]  flight an aircraft may actually have and use all three options at various stages of the flight.
[09:30.970 --> 09:36.970]  A communications management unit, CMU, is used to route ACARS traffic between the various avionics
[09:36.970 --> 09:43.550]  systems and these physical links. An airline may also change the cost preferences depending on how
[09:43.550 --> 09:49.850]  much they pay for various services. This CMU has access to lots of important avionics including
[09:49.850 --> 09:56.170]  display unit the pilot interacts with, the flight management computer for reporting location,
[09:56.170 --> 10:00.790]  and for setting height or heading as we'll see later, and for acquiring lots of maintenance
[10:00.790 --> 10:05.970]  data. And believe it or not there are actual genuine printers on the flight deck too.
[10:08.250 --> 10:14.590]  A brief segue on to cell call. During transatlantic or polar flights where radio
[10:14.590 --> 10:20.350]  communication is intermittent and to avoid crews from having to monitor radios for a long period,
[10:20.350 --> 10:25.490]  cell call was introduced where the air traffic controller can trigger an alert light or sound
[10:25.490 --> 10:31.010]  or both in the cockpit and the crew then jump on the radio to listen for the actual message.
[10:31.470 --> 10:38.190]  Each aircraft is assigned a four-digit code and the first pair of letters sent as a tone and then
[10:38.190 --> 10:44.290]  the second, which I guess is a bit like DTMF dialing tones. As you can see there aren't that
[10:44.290 --> 10:50.130]  many possible combinations so there is reuse and it's really important that crews verify the
[10:50.130 --> 10:56.950]  transmission was really meant for them. Similarly now when there is an ACARS message the crew will
[10:56.950 --> 11:02.750]  hear a chime noise and a data link message will appear on the displays which they can then go and
[11:02.750 --> 11:10.930]  read. ACARS at its basis is simply a text message service between two parties and this concept is
[11:10.930 --> 11:16.250]  now being used in air traffic control. Rather than a controller using voice radios to instruct pilots
[11:16.250 --> 11:22.770]  on what to do this is sent by a ACARS message. This has the benefits of efficiency which means
[11:22.770 --> 11:28.130]  more aircraft can be accommodated in a given space but also safety you know there is no confusion in
[11:28.130 --> 11:34.570]  hearing about what altitude to fly to or heading etc. Both Boeing and Airbus developed their own
[11:34.570 --> 11:41.810]  standards but these were merged and gave rise to the FANS 1A standard as we have today. A FANS
[11:41.810 --> 11:47.690]  installation on aircraft requires certification and a minimum latency requirement. Messages will
[11:47.690 --> 11:54.830]  be automatically rejected after 30 seconds if no confirmation is made. FANS is comprised of
[11:54.830 --> 12:01.450]  two important services which are both sent over ACARS and that could be either VHF or SATCOM.
[12:01.470 --> 12:09.710]  Controller Pilot Data Link Communication CPDLC and Automatic Dependent Surveillance Contract ADSC.
[12:11.850 --> 12:17.950]  So for CPDLC, air traffic can send pilots instructions to climb to a particular altitude
[12:17.950 --> 12:23.490]  or steer a heading. Before this can happen, pilots log on to a specific controller which
[12:23.490 --> 12:29.690]  then shows that the data link is ready. Every instruction sent by ATC requires a positive
[12:29.690 --> 12:35.310]  confirmation by the pilot. You cannot simply send a message and remote control your plane.
[12:36.030 --> 12:41.890]  Different regions still have different CPDLC adoption levels. So Europe has on-route services
[12:41.890 --> 12:48.830]  whereas parts of the USA only have pre-departure at airports. And this latter is really useful
[12:48.830 --> 12:53.170]  because if you've ever had to note down and read back a complicated departure clearance,
[12:53.170 --> 12:58.230]  you'll realize how useful this is in not only time saving but in making sure it's correct.
[12:59.810 --> 13:06.650]  You might be familiar with ADS-B which is the position notification signal sent out on 1090
[13:06.650 --> 13:12.530]  megahertz which contains GPS position and altitude. And this is picked up by services
[13:12.530 --> 13:20.130]  like Flight Radar 24 and ADS-B Exchange. These are periodically sent out by the aircraft when
[13:20.130 --> 13:27.770]  it's illuminated by primary radar. But for fans, we need more granularity and information. So ADSC
[13:27.770 --> 13:34.830]  is used instead. Air traffic can request an aircraft report its position or time when
[13:34.830 --> 13:40.970]  passing a certain altitude or a given waypoint. ADSC will also show what waypoints the aircraft
[13:40.970 --> 13:46.890]  is currently programmed to fly to. So controllers can better understand and more efficiently
[13:46.890 --> 13:54.190]  sequence traffic for arrivals into busy airports. So now we know that more ACARS is useful in broad
[13:54.190 --> 14:00.150]  terms, let's have a closer look at how the messages are formatted. In plain old ACARS,
[14:00.150 --> 14:05.130]  all messages are broadcast to all devices, or those that are in range of the same transmitter
[14:05.130 --> 14:11.130]  at least. So there is a header that lists the destination aircraft registration. The receiver
[14:11.130 --> 14:17.110]  on an aircraft will discard any messages that are not destined for it. In the header,
[14:17.730 --> 14:22.310]  there is a two-character label field which indicates the type of data that the whole
[14:22.310 --> 14:29.350]  message contains. There's no specific standard but there are some common ones like C1 which is
[14:29.430 --> 14:34.530]  a message for the onboard printer and indeed some airlines will use different labels to indicate
[14:34.530 --> 14:41.010]  the same types of data. The bulk of the transmission is taken up by the message text itself
[14:41.010 --> 14:48.050]  up to a maximum of 220 characters. The character set is basic ASCII alphanumerics and some special
[14:48.050 --> 14:54.370]  characters only and no unicode. These could just be standard free text type messages or they could
[14:54.370 --> 14:59.330]  be engineering and maintenance data and frankly more often than not it's the latter and are quite
[14:59.330 --> 15:08.230]  dull as a result. Sequential messages are sent with an incrementing number in the header so C01,
[15:08.230 --> 15:15.390]  C02 for example. Because of the 220 character limit, larger messages like our maintenance data
[15:15.390 --> 15:21.210]  can be split across multiple ACOLs transmissions or with a letter suffix to note their position
[15:21.210 --> 15:29.190]  in the multi-part message. So for example U10A, U10B, U10C etc. The next separate message
[15:29.190 --> 15:36.090]  from this particular aircraft would then be U11A and so on. The last part of the message
[15:36.090 --> 15:43.590]  is a simple checksum either ATM32 which is a modified form of Fletcher's checksum or a CRC.
[15:43.590 --> 15:49.090]  The CDU on an aircraft will discard any message without a valid checksum and ask for a retransmit
[15:49.090 --> 15:55.710]  if possible. The checksum is designed to protect against distortion of the message in transit only.
[15:55.990 --> 16:01.430]  Given we are talking about radio data links here often over long distances there is potential for
[16:01.430 --> 16:08.070]  garbled. You'll probably have noticed by now that all of the examples of message I've shown are
[16:08.070 --> 16:13.430]  actually human readable and that's because there's no encryption of the data in standard ACOLs at all.
[16:14.150 --> 16:20.110]  Some aircraft though do send encrypted messages and these are marked by the label type 44.
[16:20.590 --> 16:25.550]  There is a really great paper called Economy Class Crypto from the Oxford Aviation Security
[16:25.550 --> 16:30.010]  Group and they are able to decipher these messages through a combination of brute force
[16:30.010 --> 16:36.110]  and other inputs such as knowing where an aircraft was at the time it transmitted the message.
[16:36.110 --> 16:40.790]  What they are able to show is that there is a static cipher key in use across all of these
[16:40.790 --> 16:47.310]  terminals so its brick ones decode everywhere. Fortunately it seems that this data is mostly
[16:47.310 --> 16:52.450]  engineering rather than anything sensitive but operators of this equipment should be aware their
[16:52.450 --> 16:58.950]  messages are definitely not private. As ACOLs offers arbitrary text messaging and is often
[16:58.950 --> 17:04.810]  made available through cabin crew terminals it's common to see company type data like our second
[17:04.810 --> 17:10.470]  message here. Fortunately this particular operator seems to be aware of the limitations of ACOLs
[17:10.470 --> 17:17.310]  privacy and hasn't used names here just seat numbers but not everyone is this careful.
[17:18.990 --> 17:25.590]  Software and hardware on aircraft is written to design assurance levels. This is I suppose the
[17:25.590 --> 17:30.230]  code quality and testing that goes into that particular component depending on the risks
[17:30.230 --> 17:36.810]  that it poses to the aircraft. These hazard levels are documented in DO 178C.
[17:37.450 --> 17:42.110]  Although we've seen that ACOLs is important for efficiency both in air traffic and maintenance
[17:42.110 --> 17:46.390]  it doesn't directly impact on keeping an aircraft safe and airborne.
[17:46.710 --> 17:52.110]  This means that generally ACOLs components are into C or D levels of assurance.
[17:53.690 --> 17:59.070]  Let's step through them where ACOLs is used in different phases of flight. Airlines will provide
[17:59.070 --> 18:03.510]  routes to the air pilots to help them in choosing a fuel efficient routine or avoiding forecast
[18:03.510 --> 18:09.510]  weather, turbulence, icing and so on. The airline itself back at HQ will often calculate the
[18:09.510 --> 18:16.570]  aircraft takeoff performance speeds like V1 and V rotate based on the number of passengers, bags,
[18:16.570 --> 18:21.150]  cargo loaded and then send this directly to the aircraft for review and acceptance.
[18:21.590 --> 18:26.790]  Pilots will often do their own numbers too as a cross check. As we mentioned briefly air traffic
[18:26.790 --> 18:31.850]  control can provide departure clearances via ACOLs which will be added to the flight management
[18:31.850 --> 18:37.910]  computer once they've been checked by the pilots. The aircraft then fly that particular set of way
[18:37.910 --> 18:43.870]  points, heights and speeds after takeoff to minimize noise and improve efficiency of airspace.
[18:44.430 --> 18:48.970]  The aircraft itself has a large number of sensors attached to things like doors, cargo hatches
[18:49.590 --> 18:55.070]  and weight and wheel switches so we can work out what state it's in. This is then used to send our
[18:55.070 --> 19:01.270]  out, off, on and in data back to the airline for paying our pilots not a penny more than they deserve.
[19:04.030 --> 19:09.730]  Once in the flight the aircraft will continually be sending quite a lot of data back to the
[19:09.730 --> 19:16.310]  airline's maintenance teams and often the aircraft or engine manufacturer too so they can try and
[19:16.310 --> 19:21.250]  predict any maintenance needed. The aircraft will also immediately report things like a tail strike
[19:21.250 --> 19:27.650]  or hard landing so the aircraft can be properly inspected at the next landing. During cruise air
[19:27.650 --> 19:33.050]  traffic control will be using ACARS and CPDRC to ask the pilots to change course, routing or headings
[19:33.050 --> 19:42.710]  as they need to keep everything safe and efficient. CPDRC uses AOA, so X-25 routing as we've seen.
[19:42.890 --> 19:48.950]  The source and destination addresses are 24-bit IKO Mode S identifiers which are unique
[19:48.950 --> 19:55.410]  per aircraft and are the same ones you can see in ADS-B transmissions like on flight radar 24.
[19:56.210 --> 20:01.970]  Ground stations also have an identifier and in this message, although I've redacted the aircraft,
[20:03.810 --> 20:09.510]  29D1D7 maps to London Stansted Airport. In this case this is an acknowledgement from the aircraft
[20:09.510 --> 20:16.030]  to Stansted saying Wilco, which is short for will comply or I will do this. And this is different
[20:16.030 --> 20:23.010]  to a simple acknowledgement with no expectation that they need to do anything. Just prior to landing
[20:23.010 --> 20:29.250]  the aircraft will obtain ATIS data, Automatic Terminal Information Service, which gives data
[20:29.250 --> 20:35.730]  on the runway in use, temperature, surface wind and so on. Traditionally this has been an audio broadcast
[20:35.730 --> 20:40.590]  but by using ACARS this data can be obtained earlier and help the crew prepare for the right
[20:40.590 --> 20:47.650]  runway in use. CPDRC is not used when immediate responses might be needed. Remember it has a
[20:47.650 --> 20:53.170]  maximum of 30 seconds latency. So this is ended with arrivals and airport controller taking over
[20:53.170 --> 20:59.790]  via VHF voice. The airline will also use this position info to help prepare the gate and ground
[20:59.790 --> 21:04.570]  crew, turn the aircraft around as quickly as possible, obtain any maintenance reports, they can
[21:04.570 --> 21:13.620]  change parts out and then also be informed which aircraft is on stand for payroll. So how can you
[21:13.620 --> 21:17.960]  look at these kinds of transmissions? Well for plain old ACARS, although we have a larger number
[21:17.960 --> 21:23.700]  of frequencies and two service providers, the frequencies are quite close together. So we can
[21:23.700 --> 21:31.320]  use software defined radio like HACRF, RTL-SDR or even a digital TV tuner to receive them all in one
[21:31.320 --> 21:39.620]  go. If you look on github you'll find ACARS deck by Thierry Lecomte for RTL-SDR or the port
[21:39.620 --> 21:50.440]  of the port ACARS-SDR play by Jan Katwik for HACRF. For aerials it's VHF so you will need line of sight
[21:50.440 --> 21:57.340]  to the ground station but you will see lots of aircraft if they fly over you. A telescopic one
[21:57.340 --> 22:05.700]  will do just fine and it works okay just placed in my office window frankly. For AOA you'll need
[22:05.700 --> 22:13.180]  Jumper VDL-2 by Tomasz Lemich. This doesn't have direct HACRF support but you can use it through
[22:13.180 --> 22:21.180]  SOPI-SDR. You'll need two SDR devices to receive and decode POA and AOA at the same time though
[22:21.180 --> 22:27.960]  obviously. Many people have these little tools running on a Raspberry Pi or similar for long-term
[22:27.960 --> 22:34.180]  capture and indeed many people re-share with others out on the internet. You can use the plane
[22:34.180 --> 22:40.080]  plotter and Windows software to capture the output of the tools and draw the locations of aircraft
[22:40.080 --> 22:47.020]  from a map and so on. If you use the dash-in or dash-output HACRF's PP switches with the
[22:47.020 --> 22:51.900]  destination of the machine where plane plotter is running, this is all you need to do to capture
[22:51.900 --> 22:59.420]  these messages. Just a quick note on the legality of receiving and decoding these HACRF transmissions.
[22:59.620 --> 23:05.340]  In true internet fashion I am definitely not a lawyer and I'm in the UK so here's my take based
[23:05.340 --> 23:12.540]  on prior law, prosecution and where I live. There are still a fair number of pages, yes pages, in use
[23:12.540 --> 23:20.100]  in the UK mostly amongst the emergency services. Pager POCSAG data transmissions are quite similar
[23:20.100 --> 23:27.540]  serial data structures to HACRF's and are also really easily decoded with RTL-SDR. These generally contain
[23:27.540 --> 23:33.260]  really horribly sensitive data like patient and medical information and these are directed to
[23:33.260 --> 23:39.380]  specific recipients. So just because you can it doesn't make it legal to decode POCSAG
[23:39.380 --> 23:46.320]  in the UK. Plane or HACRF's is different because all messages have to be sent to all stations
[23:46.940 --> 23:51.040]  before they can decode them and then decide whether they are intended to be for them
[23:51.040 --> 23:56.700]  based on the registration number of the aircraft. AOA on the other hand uses x25
[23:56.700 --> 24:04.060]  and a specific terminal address for the recipient. But the legislation in the UK says you can pick up
[24:04.060 --> 24:10.140]  weather and navigation transmissions which parts of HACRF's demonstrably are. So frankly who really
[24:10.140 --> 24:15.520]  knows. I don't really want to be the test case though so I've redacted any example messages in
[24:15.520 --> 24:20.680]  this talk and I've unfortunately decided not to do a live demo just in case something sensitive
[24:20.680 --> 24:26.080]  pops up. But please check with your local jurisdiction before you start decoding these
[24:26.080 --> 24:33.000]  messages though. So I want to leave you kind of with a little thought experiment for discussions
[24:33.000 --> 24:40.160]  in the comments. HACRF's messages seem an awful lot like TCP sequence numbers. Could you predict the
[24:40.160 --> 24:48.000]  next in the sequence? Could you send a valid HACRF's message? Could you send a valid CPDLC message?
[24:48.220 --> 24:53.940]  And what if you actually did? We've noted that there's no encryption and no integrity checks
[24:53.940 --> 25:00.080]  or integrity checks rather are based on a checksign. If we were designing the system today
[25:00.620 --> 25:06.280]  would we implement encryption or message signing? Are there any potential problems if we do?
[25:08.400 --> 25:13.880]  And my final thought. Although we can see and potentially send HACRF's transmissions around
[25:13.880 --> 25:20.100]  there are always humans in the loop. We cannot take control and make an HACRF do things.
[25:20.100 --> 25:25.140]  And even if we did there are a lot of other mitigation to stop aircraft coming into conflict
[25:25.140 --> 25:31.600]  like air traffic controllers, their radar and systems like traffic collision avoidance system,
[25:31.600 --> 25:38.500]  TCAS. Yes it's a legacy system and protocol but these are vulnerabilities on the part of ARINC,
[25:38.500 --> 25:43.280]  Rockwell or CITER themselves. But we should keep in mind that when we're designing systems
[25:43.280 --> 25:47.480]  and protocols how things can end up being used 40 years on.
[25:48.700 --> 25:52.380]  Thanks for listening and I look forward to hearing your comments and thoughts.
